Legacy:Chain Of Events When A Player Logs In

rough layout

Serverside UnrealScript Events

1. GameInfo.PreLogin() – propagated to AccessControl; may reject player.
   1. Note: Required packages are downloaded before the Login function is called next. This can take some time—the level could change; another player could have gotten the slot.
2. Mutator.OverrideDownload() – called on the base mutator for each package the player needs to download, propagates down the mutator linked list (only available in UT2003, not in the base engine)
3. GameInfo.Login() – propagated to AccessControl and Mutators; spawns the PlayerPawn/PlayerController or rejects player, sets player name, spectator, admin login, other stuff:
   1. Color codes are stripped from URI options passed to the server.
   2. Mutator.ModifyLogin is called starting from the BaseMutator.
   3. Checks if server is at player capacity, in which case non-admin players will get a MaxedOutMessage, but an admin is forced to become a spectator, if the server is not at spectator capacity (?) already.
   4. Team number is picked; passing in the preferred team [0, 1], or 255 if no team is specified, or if any team will do in a team game, or perhaps if teams are not relevant to the gametype.
   5. GameInfo.FindPlayerStart is called; attempts to find a start spot for the player—could potentially abort.
   6. PlayerControllerClass is attempted loaded.
   7. Spawn player at start spot position and rotation—could potentially abort if picked start spot could not fit the player (height too low, for instance). UnrealEd 3 does not necessarily catch scenarios like these during a Reachspecs build.
   8. GameReplicationInfo reference assigned to player.
   9. SecurityClass attempted spawned for player.
   10. PlayerName
   11. Custom VoicePack
   12. Player is male or female.
   13. PlayerID is incremented and assigned to player.
   14. Admins are assigned administrative privileges.
   15. bLargeGameVOIP is set to true if the number of players is greater than 20.
   16. bWelcomePending is set to true.
   17. Determine whether level was requested to run in test mode.
   18. If bDelayedStart is true, the PlayerController enters the PlayerWaiting state.
4. GameInfo.PostLogin() – first point at which replicated functions of the new player are safe to call.
   1. Pawn.ClientSetRotation is called on the Pawn.
   2. VotingHandler is attempted set.
   3. Bandwidth is capped for the player.
   4. GameInfo.NotifyLogin is called.
   5. PlayerID hash is logged.
5. GameInfo.NotifyLogin() – calls ServerRequestBanInfo on all PlayerController actors.

Clientside Initialization Overview

TODO: What stuff gets replicated? What happens while the loading screen is visible?

Related Topics

• Chain Of Events At Level Startup
• Chain Of Events When Spawning Actors